It is currently Mon Oct 20, 2014 7:03 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 19 posts ] 
Author Message
PostPosted: Mon Apr 16, 2012 1:18 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Hi,
I've been (slowly) coding a Snake game as a fun way to learn assembler.

See http://www.retrosoftware.co.uk/forum/viewtopic.php?f=19&t=745

and http://www.retrosoftware.co.uk/wiki/index.php/JSnakeDevDiary

I've encountered a bug that I can't work out. I have a delay loop which I use to slow down the movement of the Snake to a playable speed. At the moment, the loops always decrement from same start value, but in time I would like to be able to vary said start value (to change Snake movement speed). Meanwhile, I've been changing the the start values and then compiling/running just to see any visible differences in speed.

Two issues:

1: Main issue - when I only have the delay loop cycle round a few times (I can't determine the exact value as yet) .. the Snake speeds up when say Left key (Z) is held down, but all the other directions are unaffected. Sometimes two or three directions are affected. This seems to depend on the values entered.. but I haven't established an exact pattern. If I increase the start values above a certain threshold (that I haven't established exactly yet) .. the issue disappears.

2: Observed speed up of snake movement doesn't seem proportional to delay loop start values. i.e say I have outer loop start at 192 and inner loop at 128, I can't see a visible difference until inner loop starts at 64..

At the moment, I'm more bothered about first issue.


Here is the Delay routine
Code:
.Delay   

ldx #48
.dxloop
   ldy #32
   .dyloop   
      dey
   bne dyloop
   dex
bne dxloop

lda #0 : ldx #0 : ldy #0
rts


This is called from a main loop which jumps to these subroutines, moving the snake along the screen one unit at a time until a collision occurs , i.e:
jsr Delay
jsr GetKeypress
jsr Move (animates the Snake!)
jsr CollisionDetect


I am wondering if it is something to do with the GetKeyPress routine being affected by preceding Delay routine - but if this is the case, why do I not encounter issue 1 regardless of values in the inner and outer loops?

Here is an excerpt of the GetKeyPress routine:

Code:
   ldx #Key_Z
   jsr inkey
   bne LeftPressed
   ldx #Key_X
   jsr inkey
   bne RightPressed
   ldx #Key_Colon
   jsr inkey
   bne UpPressed
   ldx #Key_ForwardSlash
   jsr inkey
   bne DownPressed
   
   jmp GKPEnd ; no key pressed
   
   .LeftPressed   
   lda SnakeDirection
   cmp #DirRight
   beq IgnoreLeftKey
   lda #DirLeft
   sta SnakeDirection
   
.IgnoreLeftKey
   rts
              .
              .
              . 
             same idea for rest of directions
             .
             .


And the inkey subroutine:

Code:
.inkey ; routine from Creative assembler book
   PHA         ;Save A
   TYA        ; Save Y
   PHA
   LDY #&FF    ;Negative numbers
   LDA #&81   ; osbyte &81 is INKEY
   JSR osbyte ; Do it
   PLA         ;Restore Y
   TAY
   PLA        ; Restore A
   CPX #&00   ; Adjust zero flag
RTS        ; and return



Any help or suggestions on troubleshooting this would be gratefully received.

Thanks,
jbnbeeb


Top
 
PostPosted: Mon Apr 16, 2012 2:31 pm 
Offline
 Profile

Joined: Fri Nov 07, 2008 2:28 pm
Posts: 65
For a mainloop I'd do something like this:

Code:
MAINLOOP:
    JSR VSYNC
    JSR GETKEYS
    JSR MOVE
    JSR COLLISION
    JMP MAINLOOP

where VSYNC waits for the next 50hz frame - that means your game can't loop super fast. (It could run slower of course)


Code:
VSYNC:
        LDA    #&13
        JSR    _OSBYTE
        RTS



If I wanted the character to run slower I could still run the game at 50hz but could use a fractional position like this:

Code:
LDA xpos_fraction
CLC
ADC #&80
STA xpos_fraction
LDA xpos
ADC #0
STA xpos


So xpos would move 1 pixel every 2 frames

or ADC #&40 to move 1 pixel every 4 frames etc.






Your wait loop looks ok but the changing your X value has 32 times the effect of changing the Y value.

This version that has a fixed Y loop amount would be proportional based on the input X, I put a couple of nops in the middle to make it even slower...


Code:
LDX #10
JSR WAIT

; this is twice as long as before
LDX#20
JSR WAIT


WAIT:
.dxloop
   ldy #0
 .dyloop   
   nop
   nop
   dey
   bne dyloop
   dex
   bne dxloop
   rts


- PJ


Top
 
PostPosted: Mon Apr 16, 2012 5:50 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Thanks for the advice PJ.

I adapted your xpos fraction idea and placed this in my Move routine.

I am using Vsync code from SteveO http://www.retrosoftware.co.uk/wiki/index.php/MovingSpritesMode2

I was using it from my Move routine but I'm now calling it from Main loop. I've dropped the delay loop in favour of the xpos fraction idea, but unfortunately I still have my main issue (see issue 1 above) in that the Snake moves faster when a particular direction key is pressed.

I did some more testing and concluded that the GetKeyPress routine was the culprit. Whichever key I was trying to read first in the routine was the one that caused the Snake to move faster.

I then had a read around, and am now using osbyte &79 to scan the keyboard from internal key 66 (X) upwards. I thought this would make things quicker as now I only have to call osbyte once to capture the internal key code. This hasn't cured the issue and has only made me more confused. Note the order I capture keys in code snippet below. My testing is showing that pressing "/" (Down) moves the Snake fastest, while pressing ":" (up) is moving the snake a bit faster. Otherwise, the snake speed remains constant whether no keys are pressed, or left or right is pressed. I'd like the speed of the snake to remain constant regardless of any keys are pressed or not, as this is like Acornsoft Snake or Hypervyper in that the snake continues to move in whichever direction was last pressed on keybd.

When I was using the delay loop in my first post (with higher values).. I didn't get this problem at all, the snake moved at a constanst speed, and I was able to get it to go quite fast.. but there was a limit, at which point I encountered the same issue as I have now.

Once again, any thoughts on what is happening and what can be done to resolve it would be appreciated. I'm stumped at present as my keybd routine doesn't look radically different to some of the source code for games on this site.

Code:
   lda #&79
   ldx #66
   jsr osbyte
   
   cpx #Key_ForwardSlash
   beq DownPressed
   
   cpx #Key_Z
   beq LeftPressed
   
   
   cpx #Key_X
   beq RightPressed
   
   cpx #Key_Colon
   beq UpPressed
   
   
   
rts   ;jmp GKPEnd ; no key pressed
   
   .LeftPressed   
   lda SnakeDirection
   cmp #DirRight
   beq IgnoreLeftKey
   lda #DirLeft
   sta SnakeDirection
             .
             .


Top
 
PostPosted: Mon Apr 16, 2012 8:15 pm 
Offline
User avatar
 Profile

Joined: Mon Jan 07, 2008 7:02 pm
Posts: 273
You don't want to use OSBYTE &79 for this, I'd suggest going back to your older code. I can't see anything particularly wrong with the code in your first post, could you post the entire movement routine?


Top
 
PostPosted: Mon Apr 16, 2012 8:31 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Hi,

Move routine as requested.


Code:
   
.Move


                                
  ;jmp GetOldHead
      ;==wipe old tail 2x3 blob from screen
      ;retrieve x,y co-ords of  old tail
   
   CLC
   LDA DelayFraction
   ADC #&20
   STA DelayFraction
   LDA DelayCounter
   ADC #0
   STA DelayCounter
   lda DelayCounter
   bne EofDelay
   rts   
   
      
   .EofDelay
   lda #0
   sta temp_val
   sta temp_val+1
   COMP16 GrowSnakeCounter, temp_val
   beq WipeTail
   
   DE16 GrowSnakeCounter
   ;jsr UpdateBanner
   jmp GetOldHead
   
   .WipeTail   
      ldx #0
      lda (snaketail_ptr,X)
      sta XOrd
      
      jsr IncSnakeTailPtr
      lda (snaketail_ptr,X)
      sta YOrd
      
      ;eor retrieved x,y co-ords (actually eor the calculated screen address of the x,y co ords with the screen itself)
      ldy #0
      ldx #0
      lda #0
      jsr ScreenStartAddress
      lda #&0C
      eor (XYScreenAddress,X)
      sta (XYScreenAddress,X)
      inc YOrd
      jsr ScreenStartAddress
      lda #&0C
      ldx #0
      eor (XYScreenAddress,X)
      sta (XYScreenAddress,X)
      inc YOrd
      jsr ScreenStartAddress
      lda #&0C
      ldx #0
      eor (XYScreenAddress,X)
      sta (XYScreenAddress,X)
      dec YOrd
      dec YOrd   
      ;(increment tail pointer)
      jsr IncSnakeTailPtr
      
      ;===================================
      
      
   .GetOldHead
      
      ldx #0
      jsr DecSnakeHeadPtr
      lda (snakehead_ptr,X)
      sta XOrd
      
      jsr IncSnakeHeadPtr
      lda (snakehead_ptr,X)
      sta YOrd  ; coords of old head
      
      lda #0
      ldx #0
      ldy #0
      
   .PlotNewHead   
   
      lda SnakeDirection : cmp #DirLeft : beq mvLeft
      cmp #DirRight : beq mvRight
      cmp #DirUp : beq mvUp
      cmp #DirDown :beq mvDown
      
      
      .mvLeft
      dec XOrd : jmp PlotBlob
      
      .mvRight
      inc XOrd ;x ord of new head      
      jmp PlotBlob
         
      .mvUp
      sec :lda YOrd :sbc #3
      sta YOrd
      jmp PlotBlob
      
      .mvDown
      lda #2   
      adc YOrd
      sta YOrd
      jmp PlotBlob
      
      .PlotBlob      
      jsr IncSnakeHeadPtr
      ldx #0
      lda XOrd
      sta (snakehead_ptr, X)
      jsr IncSnakeHeadPtr
      lda YOrd
      sta (snakehead_ptr, X)
      
      ldx #0
      lda #0
      ldy #0
      
      jsr ScreenStartAddress
      lda #&0C
      eor (XYScreenAddress,X) : sta (XYScreenAddress,X)
      sta snakehead_scrn_addr ; store EORed result of plotted pixel - ie it's colour. If it is green (&0C), no collision, otherwise, we have a collision.
      inc YOrd
      jsr ScreenStartAddress
      
      lda #&0C
      ldx #0
      eor (XYScreenAddress,X) :sta (XYScreenAddress,X)
      sta snakehead_scrn_addr+1
      
      inc YOrd
      jsr ScreenStartAddress
      lda #&0C
      ldx #0
      eor (XYScreenAddress,X) : sta (XYScreenAddress,X)
      sta snakehead_scrn_addr+2
      dec YOrd
      dec YOrd   
rts
;End Move


Top
 
PostPosted: Tue Apr 17, 2012 8:22 am 
Offline
User avatar
 Profile

Joined: Fri Apr 25, 2008 7:55 pm
Posts: 147
Is your code interrupt driven in any way? In these circumstances where there's apparently nothing amiss, I usually expect to find that say X or Y are getting corrupted by some interrupt code and thus shortening (or lengthening) the loop. Just a thought.... ;)


Top
 
PostPosted: Tue Apr 17, 2012 1:36 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Yes MartinB, this is a good point that I haven't thoroughly investigated yet. The vsync routine I'm using generates an interrupt. I've taken this from the sprite plotting example by Steve O'Leary in the Sample Code section of this site - snippet below.
http://www.retrosoftware.co.uk/wiki/index.php/MovingSpritesMode2

Yesterday I was focussing on the keyboard routine. I ended up using yet another excellent bit of sample code, this time from Richard Talbot-Watkins:
http://www.retrosoftware.co.uk/wiki/index.php/Reading_the_keyboard_by_direct_hardware_access

I disable , then re-enable interrupts around each key check. This is definitely a much quicker read key routine. I had to adjust the "DelayFraction" as suggested by PJ above to a lower value in the Move routine to compensate.

However, at certain speeds of snake movement, I get the same issue of the Snake speeding up when I hold down the Left or Right keys (left seems to move fastest.. or whichever key I check first in the read key routine). Left moves the snake quicker when I adjust the DelayFraction value higher .. &20 and above.. ie only moving snake every 8th frame. Sweetspot, with no speed up of snake when any direction key is held down seems to be &10.

So at some speeds the snake speed is affected (increases) by the keyboard routine for so long as left or right keys are held down. I don't understand why it isn't affected regardless of DelayFraction setting.

My aim is to a) not have the snake speed affected by holding down a key, b) to be able to control the speed of snake movement.. e.g. when player gets above a given score, increase snake speed.

I reset the registers to 0 when calling many routines. How do I check for register corruption without affecting the registers :) ?






Code:
sei                                     ; first things first turn off interupts when
                                           ; programming system via
 
  ; Set the code to execute when an interupt occurs (which will be the vsync interupt)
                                           
  LDA #LO(IRQHandler)                      ; set the interupt request to be ours
  STA InteruptRequestVectorLow             ; we don't preserve anything previous
  LDA #HI(IRQHandler)                      ; note as interupts disabled it's safe to do this
  STA InteruptRequestVectorHi
   
 
  ; set CA1 to interupt when Vysync occurs
 
  LDA #%01111111                          ; disable all 6522 interupts
  STA SysVIA_InteruptEnable               ; we just want the ones we're interested in
  LDA #%10000010                          ; enable CA1 interupt (VSync input from 6845)
  STA SysVIA_InteruptEnable
  LDA #%00000100                          ; Set CA1 to interupts when it gets a positive
                                          ; edges, i.e. goes from 0 to 1
  STA SysVIA_PeripheralControl 
 
 
   ; following sets timer 1 to timed interupt each time Timer1 loaded,Shift register
  ; disabled,PB,PA Latches disabled     
  LDA #0       
  STA SysVIA_AuxControl
  STA EndOfDisplayReached;
  cli                                     ; finished setting up via, enable interupts 
 
  rts
 
     
 ;
 .IRQHandler 
 ; fires when the interupt occurs.
 
  LDA SysVIA_InteruptFlag           ; look at the interupt flags of the system via
  AND #%00000010                    ; mask out all but CA1 (which is linked to Vsync
                                    ;  circuit), if set CA1 has had an active edge.
  BEQ NotVysncInterrupt             ; not set check other interupts
                           
  STA SysVIA_InteruptFlag           ; is set so vsync occurred, storing back clears interupt flag
 
  LDA #%11000000                    ; enable timer 1 interupt
  STA SysVIA_InteruptEnable
  LDA #$C8                          ; set timer1, this value is critical to the smooth scrolling of the routine
  STA SysVIA_Timer1CounterLatchLow
  LDA #$46
  STA SysVIA_Timer1CounterLatchHi
 
  lda # 0
  sta EndOfDisplayReached           ; Set to false           
  LDA $FC                     ; on entrying interupt A is put in FC, so get back
  rti                               ; exit the interupt
 
  .NotVysncInterrupt   
  LDA SysVIA_InteruptFlag           
  AND #%01000000                    ; checking if interupt was timer1
  BNE Timer1Interrupt               ; it was timer 1
  LDA $FC                     ; on entrying interupt A is put in FC, so get back
 RTI
 
  .Timer1Interrupt                       
    ; timer 1 has counted down so the CRT has just finished rendering the visible part
    ; of the display
    STA SysVIA_InteruptFlag         ; clear interupt flags
    STA SysVIA_InteruptEnable
    dec EndOfDisplayReached         ; previous value was 0 so this makes it not zero     
  LDA $FC                     ; on entrying interupt A is put in FC, so get back
  rti
 


Top
 
PostPosted: Tue Apr 17, 2012 9:00 pm 
Offline
User avatar
 Profile

Joined: Fri Apr 25, 2008 7:55 pm
Posts: 147
The responsibility for protecting registers really lies with any interrupt-called code and to be honest, /most/ of the ofiicial OS routines do just that. If you want to try a quick test, put an SEI at the start of your delay loop and a CLI at the end. This isn't ideal for your end product (unless that's what you want it achieve - i.e. an exclusive delay-only monopoly) but it might well give you a good clue ;)

In your own callable routines, the basic register protection is acieved through the usual PHA TYA PHA TXA PHA or similar followed by the reverse before the RTS or, for greater speed, store the three directly to a zp triple. Since you don't call anything from within your delay loop, it must be something external (interrupt code) that is rogering your count but you can't protect the delay code from that unless you again use a couple of private zp locations as your inner/outer counters. Again, this would also give you a clue as to where the problem might lie.


Top
 
PostPosted: Tue Apr 17, 2012 9:23 pm 
Offline
 Profile

Joined: Fri Nov 07, 2008 2:28 pm
Posts: 65
As I understand it you can only use zero page from $00-&9F as the rest is used by the OS: sound, vdu calls and the like - are you using safe zero page addresses?

If your game was running fast enough to begin with - I'd stick with the OSBYTE keyboard calls - I found using the hardware directly can be a total pain. (I only did it in my case because I needed the speed).

- PJ


Top
 
PostPosted: Tue Apr 17, 2012 9:42 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Thanks for the feedback Martin and PJ.

MartinB - for the time being I've now dispensed with the delay loop altogether and used the count ("DelayFraction") idea from PJ in second post above, though the snake moves more smoothly in my old code with the delay loop set at certain start values - and speed not affected by keypresses... otherwise, as per my first post, I get the same speed up issues regardless of what I've tried thus far.

Noting MartinB's comments, I wonder if I should modify the vsync interrupt code listed above by saving /restoring registers in zp triple. At present, it seems the code doesn't save/restore contents of registers?

jbnbeeb


Top
 
PostPosted: Tue Apr 17, 2012 10:24 pm 
Offline
User avatar
 Profile

Joined: Fri Apr 25, 2008 7:55 pm
Posts: 147
The vsync code above only uses A, not X or Y. A is saved in $FC by the initial OS code and restored just prior to the RTI so no, that particular code isn't responsible for any corruption of X and/or Y. I was initially referring to any other code you might be using in your game, maybe where you move the snake in response to an interrupt?


Top
 
PostPosted: Fri May 04, 2012 7:28 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Hi all,
I'm still struggling to fix this issue. Essentially, the symptom is that when a direction key is held down in my snake game, the snake moves faster than if no key is pressed - but usually only in two directions.

I wouldn't say I've drawn a definitive conclusion but here is what I *think* is going on:

- When no keys are pressed, the game loop calls the keybd checking routine on each iteration

- With no key pressed, the keybd checking routine will always take the same no. of cycles to execute, thus when the game loop calls the move snake routine, snake moves at a uniform rate

- The first two directions checked are Left and Right. Holding these keys down results in snake moving faster. I think this is because the checks are earlier in the routine which I then rts out of once a given keypress is detected), thus on this occasion, routine has taken fewer cycles, and Move routine is then called sooner.

- As up and down direction keys are checked later in the routine, the difference in no. of clock cycles to run the routine is smaller, and thus snake movement isn't noticeably faster

The only interrupt code written in the program is the vsync routine as discussed above. I do sei / cli around the check for each key at the moment.

I am using PJ's idea earlier in this thread so that the snake only moves every x no. of frames as a means of controlling rate of snake movement. Setting the "counter" at certain values results in a steady speed of snake. Other values result in the issue I'm discussing here. I also encountered this issue in my initial code, where I had an empty delay loop to control speed.

Any further hints and thoughts would be much appreciated as I've been battling with this for some time.

I could upload ssd and assembler (Beebasm) source if it would help?


Thanks,
jbnbeeb


Top
 
PostPosted: Sat May 05, 2012 4:17 am 
Offline
 Profile

Joined: Fri Nov 07, 2008 2:28 pm
Posts: 65
Post the source.
-PJ


Top
 
PostPosted: Sat May 05, 2012 3:04 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Hi,
source code attached as requested. There're several routines that could be rewritten now I'm a bit more proficient.. the routines I've been mentioning where I think the problem could be is in:

.GetKeyPress and .Move

PJ, Look out for first few lines in .Move where I've used your "draw every x times routine is called" idea

Thanks,
jbnbeeb


Attachments:
jsnake_src.zip [12.29 KiB]
Downloaded 7 times
Top
 
PostPosted: Sat May 05, 2012 4:00 pm 
Offline
 Profile

Joined: Fri Nov 07, 2008 2:28 pm
Posts: 65
Crazy fast!

I think this fixes it - look for ;PJ in the code for the changes.

I added a new variable vsync_happened which I set to 1 as soon as vsync has occured.

I replaced your VSYNC wait with VSYNC_NEW which waits for vsync_happened to be set and then clears it.

I removed any wait at all in your move routine.

It looks like your setting a timer in vblank and then waiting for the timer to time out whereas I'm just waiting for vblank.

I general I'd not use your own IRQ Handler at all as you lose all the good things the OS gives you (like sound and keyboard) - unless you JMP(oldvec) at the end of the IRQ instead of RTI.

Nice to see lots of comments - and I never thought about tabbing 6502 like 'c' - that's an idea! (so old school here)

My only other comment is I like to setup my zero page with ORG &00 and GUARD &A0 with EQUBs and/or SKIPs - so that way you ensure you don't use a location twice and it's tidier, and it really easy to add or remove variables.

-PJ

Attachment:
jsnake_fix.zip [12.01 KiB]
Downloaded 11 times


Top
 
PostPosted: Sat May 05, 2012 5:08 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Thanks for the fix PJ! Much appreciated!

The code I was using for the vsync + timer was SteveO's code from the sample pages here (Mode 2 sprite plotting). I think the logic behind it was it bought extra time to do your updates between screen refreshes. I'm probably using it wrong.

Waiting for vsync (only, bypassing the custom IRQ) certainly makes animation smooth.. is there any way to get the snake to move faster and still be tied to vsync? I'm guessing not, short of moving in greater increments of pixels which would look a bit jerkier? And I presume that if I don't tie to vsync (or if I tied the game loop to say half vsync value).. I'd get tearing.

I want to be able to make the Snake progressively faster at certain score thresholds.


Top
 
PostPosted: Tue May 08, 2012 3:24 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Sorry if I'm wearing people out with this thread. If anyone has any patience left to read through this post I'd be most grateful.

PJ kindly took a look at my code and simplified it such that it simply waits for vsync to occur before calling the getkeys and move snake routines. This makes the snake move smoothly but appears to me moving as fast as it can go in increments of 2 pixels.

I'd like to make it move faster as a game feature when the player reaches a given score.

So with current code.. I can't understand why the snake isn't moving faster. I say this with following (possibly false) assumptions:

a) Vsync = 50 frames per second.
b) Move routine is called once vsync occurs
c) Move routine moves snake in x direction by two pixels
d) so my move routine is being called 50 times a second?

If so - why isn't the snake moving at a rate of 100 pixels per second?

I've also used Richard Talbot-Watkins's "coloured band" idea to see if move routine is eating into the time when screen is being updated. Most of the time it isn't, with no more than a char row's worth of coloured band appearing across the top of the screen very occasionally.


Top
 
PostPosted: Tue May 08, 2012 5:13 pm 
Offline
 Profile

Joined: Fri Nov 07, 2008 2:28 pm
Posts: 65
Actually if you run at 50Hz you can move any amount and it will be 'smooth' - because the screen update is fast enough to fool your eyes.
Just call you move routine multiple times now and it runs super fast - like this:

Code:
             jsr VSYNC_NEW
         jsr GetKeyPress
         lda #0 : ldx #0 : ldy #0
         jsr Move
              lda #0 : ldx #0 : ldy #0
         jsr Move


The only problem is in order to not be jerky you have to move if the same amount every frame so you speeds are limited to 1 wide pixel, or 2 wide pixels, or 3 wide pixels etc.

If you try moving it 1 pixel and then 2 pixels on alternative frames to get an in between speed then it would be jerky.

So- you really have to plot things at sub-pixels within the byte (maybe you do this already?) to get in-between speeds.

-PJ


Top
 
PostPosted: Tue May 08, 2012 7:32 pm 
Offline
User avatar
 Profile

Joined: Thu Feb 02, 2012 4:24 am
Posts: 68
Ah - thanks PJ. I had thought of moving in greater pixel increments but I thought this wouldn't be as smooth. I still wonder why the initial movement in increments of 2 pixels (aka 1 wide pixel) isn't resulting in a rate of 100 pixels a second if screen update is 50 times a second?

I don't currently do the sub-pixel idea though I will look to implement for a more gradual increase in snake movement rate between "normal" and "super-fast" :)

Then I'll try and improve the graphics a little bit and look to wrap up the Snake game for now.

Being a glutton for punishment, I want to have a go at doing Snake in Java for Android platform (so I'll have to learn Java :) )


Top
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: